home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 933 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.7 KB
  1. Date: Thu, 21 Jul 1994 09:08:18 -0400 (EDT)
  2. From: Rick Flashman <rflashma@mhc.mtholyoke.edu>
  3. Subject: Re: Dialogs!
  4. To: gem-list@world.std.com
  5. In-Reply-To: <Pine.3.87.9407210138.A781-0100000@grad>
  6. Message-Id: <Pine.3.89.9407210852.F6597-0100000@mhc.mtholyoke.edu>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. On Thu, 21 Jul 1994, Timothy Miller wrote:
  11.  
  12. > Hey, people!
  13. > 
  14. > We're saying to stop using dialogs.
  15. > 
  16. > Ok... you just threw away part of the OS and told peope to replace it 
  17. > with their own code (or a library).
  18. > 
  19. > Hey, this is the way GEM is.  If we're going to require dialogs to be in 
  20. > windows, then it should made part of the operating system.  
  21.  
  22. Geneva includes documented support for placing dialogs in windows.
  23.  
  24. > If we want all dialogs to be in windows, then we have to go knocking on 
  25. > the doors of the OS developers and demand that they change the basic 
  26. > functionality of the OS.  MultiTOS and Geneva should put dialogs for apps 
  27. > automatically into windows and handle them accordingly.
  28.  
  29. Errr...  Think about it. This is nowhere as easy as you think. And if you 
  30. manage to pull it off, most older programs will simply crash when a 
  31. non-dialog part of it is accessed while the user is in a dialog.
  32.  
  33. > But then you screw over everyone using an older machine without Geneva or 
  34. > MultiTOS, and you screw up every older program running under the new OS 
  35. > that expects the dialog box to stay in the same spot.
  36. > 
  37. > You're not asking for extentions to the OS, consistency, and added 
  38. > functionality.  You're asking for REVOLUTION!  And as you know revolution 
  39. > does not come without a BIG price.
  40.  
  41. Here's the basic problem. You cannot cause a REVOLUTION on a machine if
  42. 90% of all the software anyone will use on it is already written. That the
  43. basic difference between MultiTOS and Geneva. MultiTOS was written so that
  44. developers can take advantage of it (with very little support for older
  45. applications). Geneva was written for current applications (with support
  46. for new applications). 
  47.  
  48. > I'm as supportive of dialogs-in-windows as the next guy, but we have to 
  49. > face reality.  Good option, yes.  Requirement?  Definately NOT!
  50.  
  51. No program should do one or the other. I prefer the option (user 
  52. selectable). Then if the application runs out of windows (like it does 
  53. easily on a 7 window system) it starts using dialog boxes until windows 
  54. are available again.
  55.  
  56. > Every new program that supports that section of the GEM-List standards 
  57. > should put dialogs in windows.  Fine.  Every program that wants to 
  58. > properly support multuitasking, definately.
  59.  
  60. See above.
  61.  
  62. > But then you still have the problem of every program containing extra 
  63. > code for handling dialogs in windows, and each program having a different 
  64. > handler from a different library developer.  There will be a lack of 
  65. > consistency and a lot of wasted space.
  66.  
  67. There already is.
  68.  
  69. > Until this is part of the OS, you can't make it a requirement.  A little 
  70. > 5k DA that's intended to make some setting and then quit certainly 
  71. > shouldn't be required to puts its dialog in a window.  You won't have the 
  72. > dialog open long enough!
  73.  
  74. Which OS? We've put support into Geneva. What other environments 
  75. have/don't have this support?
  76.  
  77. > Can someone tell me how to set up menu_popup's?  I'm baffled.  Do I 
  78. > create a form with just string in it and put that in the MENU structure?  
  79. > I'm kinda lost.  Could someone explain the process that one goes 
  80. > through?  What do you do in the resource editor, what you do in your 
  81. > code, etc?  Thanks!
  82.  
  83. You obviously need Geneva. Sample code is included. (tongue-in-cheeck) ;-)
  84.  
  85.  
  86. --
  87. Rick Flashman, Gribnif Software                        Tel 413.247.5620
  88. P.O. Box 779, Northampton, MA 01061-0779               Fax 413.247.5622
  89. For customer support/information please email "gribnif@genie.geis.com".
  90.  
  91.